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Abstract 

We describe a scheme for moving living code between a set of distributed processes coor- 
dinated with unification based Linda operations, and its application to building a compre- 
hensive Logic programming based Internet programming framework. Mobile threads are 
implemented by capturing first order continuations in a compact data structure sent over 
the network. Code is fetched lazily from its original base turned into a server as the con- 
tinuation executes at the remote site. Our code migration techniques, in combination with 
a dynamic recompilation scheme, ensure that heavily used code moves up smoothly on a 
speed hierarchy while volatile dynamic code is kept in a quickly updatable form. Among 
the examples, we describe how to build programmable client and server components (Web 
servers, in particular) and mobile agents. 

Keywords: mobile computations, remote execution, networking, Internet programming, 
first order continuations, Linda coordination, blackboard-based logic programming, mobile 
agents, dynamic recompilation, code migration 



1 Introduction 

Data mobility has been present since the beginning of networked computing, and 
is now used in numerous applications - from remote consultation of a database, to 
Web browsing. 

Code mobility followed, often made transparent to users as with network files 
systems (i.e. Sun's NFS). Java's ability to execute applets directly in client browsers, 
can be seen as its most recent incarnation. 

Migrating the state of the computation from one machine or process to another, 
still requires a separate set of tools. Java's remote method invocations (RMI) add 
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control mobility and a (partially) automated form of object mobility i.e. integrated 
code (class) and data (state) mobility. The Oz 2.0 distributed programming pro- 
posal of ( |Van Roy et al., 1997| ) makes object mobility more transparent, although 
the mobile entity is still the state of the objects, not "live" code. 

Mobility of "live code" is called computation mobility ( |Cardelli, 1997| ). It requires 
interrupting the execution, moving the state of a runtime system (stacks, for in- 
stance) from one site to another, and then resuming execution. Clearly, for some 
languages, this can be hard or completely impossible to achieve. 

Telescript and General Magic's Odyssey ( |GeneralMagicInc., 1997| ) agent pro- 
gramming framework, IBM's Java based aglets, as well as Luca Cardelli's Oblique 
dBharat fc Cardelli, 19951 ), have pioneered implementation technologies with com- 
putation mobility. 

This paper will show that we can achieve full computation mobility through our 
mobile threads, with no need for a specially designed new language. It is imple- 
mented by a surprisingly small, source level modification of the BinProlog system, 
which takes advantage of the availability of first order continuations 1 as well as of 
BinProlog's high level networking primitives. Mobile threads complete our Logic 
Programming based Internet programming infrastructure, built in view of creat- 
ing Prolog components which can interoperate with mainstream languages and 
programming environments. Mobile threads can be seen as a refinement of mobile 
computations, as corresponding to mobile partial computations of any granularity. 
Mobile agents can be seen as a collection of synchronized mobile threads sharing 
common state ( |Tarau fc Dahl, 19 96). We achieve synchronization using a variant 
of the Linda coordination protocol. 

The paper is organized as follows: 

• section[2]describes our networking infrastructure and Linda based client /server 
components 

• Section [3] describes our code migration and code acceleration techniques (dy- 
namic recompilation) 

• Section 0] describes our mobile computation mechanism, as follows: subsec- 
tion ^21 introduces engines and threads, subsection l4.3|) reviews the underly- 
ing binarization mechanism used to implement our first order continuations, 
subsection 14 . 41 explains how we implement thread mobility by capturing con- 
tinuations (subsection 14.4. Q and moving them from their base to their tar- 
get (subsection 14 . 4 . 2() . how this can be emulated with remote predicate calls 
(subsection 14.4. and how mobile agents can be built within our framework 
(subsection 14.5(1 

• section [5] discusses related work 

• section [5] presents our conclusions and future work 

The main "paradigm independent" novelties of our contribution are: 

• use of first order continuations for implementing mobile computations 

1 I.e. continuations (representations of future computations) accessible as an ordinary data struc- 
ture - a Prolog term in this case. 
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• a flexible thread mobility algorithm expressed in terms of client-server role 
alternation and communication through Linda operations 

• a technique, based on intuitionistic assumptions, for dealing with complex 
networking code component-wise 

Our contributions are synergctically integrated into a powerful agent building in- 
frastructure, which brings together logic programming based knowledge processing, 
Linda-style coordination, and live code migration through mobile threads. 



Our networking constructs are built on top of the popular Linda ( |Carriero fe Gelern tcr, 1989 
|Ciancarini, 19 94 Dc Boss chere fc Tarau, 1996||P. Ciancarini et al, 1996||Microsystems, 1 999) 
coordination framework, enhanced with unification based pattern matching, remote 
execution and a set of simple client-server components merged together into a scal- 
able peer-to-peer layer, forming a 'web of interconnected worlds': 

out(X): puts X on the server 

in(X) : waits until it can take an object 

matching X from the server 
all(X,Xs): reads the list Xs matching X 

currently on the server 



Fig. 1. Basic Linda operations 

The presence of the all/2 collector avoids the need for backtracking over multi- 
ple remote answers. Note that the only blocking operation is in/1. Typically, dis- 
tributed programming with Linda coordination follows consumer-producer patterns 



2 Basic Linda and Remote Execution Operations 



2. 1 Coordination of Linda clients 
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(see Fig. ^ with added flexibility over message-passing communication through as- 
sociative search. Blocking rd/1, which waits until a matching term becomes avail- 
able, without removing it, is easily emulated in terms of in/1 and out/1, while 
non-blocking rd/1 is emulated with all/2. 

2.2 Remote Execution Mechanisms 

The implementation of arbitrary remote execution is easy in a Linda + Prolog sys- 
tem, due to Prolog's metaprogramming abilities, which allow us to send arbitrary 
Prolog terms over the network in a uniform way, without the need for implementing 
complex serialization/remote object mechanisms. Our primitive remote call opera- 
tion is: 

host (Other_machine)=>> 

remote_run (Answer .RenioteGoal) . 

It implements deterministic remote predicate calls with (first)-answer or 'no' re- 
turned to the calling site. 

For instance, to iterate over the set of servers forming the receiving end of our 
'Web of Worlds', after retrieving the list from a 'master server' which constantly 
monitors them making sure that the list reflects login/logout information, we sim- 
ply override host/1 and port/1 with intuitionistic implication =>> ( |Tarau, 1998a 
|Dahl et a/.,T997| ): 

ask_all_servers (Channel , Servers , Query) : - 
member(server_id(Channel,H,P) .Servers) , 
host (H) =»port (P) =» 

ask_a_server (Query ,_) , 
f ail ; true . 

Note that a Channel pattern is used to select a subset of relevant servers, and 
in particular, when Channel is a "match all" free logical variable, all of them. 
By using term subsumption this allows building sophisticated "publish/subscribe" 
communication pattern hierarchies. 

2.3 Servants: basic Linda agents 

A servant is one of the simplest possible agents, which pulls commands from a 
server and runs them locally: 

servant : - 

in(todo(Task) ) , 
call (Task) , 
servant . 

Note that servant is started as a background thread. No 'busy wait' is involved, 
as the servant's thread blocks until in(todo (Task) ) succeeds. More generally, dis- 
tributed event processing is implemented by creating a 'watching' agent attached 
to a thread for each pattern. 

As servants pulling commands are operationally indistinguishable from servers 
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acting upon clients' requests, they can be used as emulators for servers. A class of 
obvious applications of this ability is their use as pseudo-servers running on ma- 
chines with dynamically allocated IP addresses (as offered by most ISP today), 
laying behind firewalls. This mechanism also works when, because of security re- 
strictions, server components cannot be reached from outside, as in the case of Java 
applets which cannot listen on ports of the client side machine. 



2-4 Server side code 

Servants as well as other clients can connect to BinProlog servers. Higher or- 
der call/N | |Mycroft fc O'Keefe, 1984| ), combined with intuitionistic assumptions 
' '=>>' ' , are used to pass arbitrary interactors to generic server code: 



run_server (Port) :- 

new_server (Port , Server) , 
register_server (Port) , 
server (Server) =»server_loop , 
close_socket (Server) . 

server_loop : - 
repeat , 

interact , 
assumed(server_done) , 
! . 

interact : - 

assumed (Interactor) , 
assumed(Server) , 

'/, higher-order call to interactor 
call (Interactor, Server) . 

Note the use of a specialized server-side interpreter server_Loop, configurable 
through the use of higher-order 'question/answer' closures we have called inter- 
actors. 

The components of a 'generic' default server can be overridden through the use of 
intuitionistic implication to obtain customized special purpose servers. The use of 
intuitionistic implications (pioneered by Miller's work (Miller, 1989)) helps to over- 
come (to some extent) Prolog's lack of object oriented programming facilities, by 
allowing us to 'inject' the right interactor into the generic (and therefore reusable) 
interpreter. BinProlog's ' '=>>' ' temporarily assumes a clause in asserta order, 
i.e. at the beginning of the predicate. The assumption is scoped to be only usable to 
prove its right side goal and vanishes on backtracking. We refer to ( |Tarau, 1 998a 
|Tarau et al., 1996a| |Dahl et a/., 19971 ) for more information on assumptions and 
their applications. 
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2.5 Modular HTTP server component building: do or delegate 

We will show in this section a typical application of our component based server 
building technology: how to enhance efficiently the HTTP protocol, to handle server 
side Prolog scripts directly, without using CGIs or vendor specific server side ex- 
tensions. 

The top goal of the HTTP server looks as follows: 

run_http_server : - 

server_action(http_server_action) =»run_server . 

http_server_action(ServiceSocket) : - 

socket (ServiceSocket)=>>http_server_step(ServiceSocket) . 

The http_server_action is passed to the inner server loop using intuitionistic 
implication. This allows reusing general server logic, independently of a particular 
protocol. The action itself is described in http_server_step: it consists of prepar- 
ing a fall-back mechanism to a standard HTTP server, unless the request is for a 
file recognized as Prolog code, using the redirection facilities built in the HTTP 
protocol. 

http_server_step(Socket) :- 

( assumed(fallback_server (FallBackServer) ) ->true 

; FallBackServer="http : //localhost : 80" 

), 

server_try (Socket , sock_readln(Socket , Question) ) , 
http_get_client_header (Socket .Header) , 

http_process_query (Socket , Quest ion, Header .FallBackServer) . 

Our very simple query processor uses Assumption Grammars ( |Dahl et a/., 1997| ). 
Their ability to handle multiple DCG streams ( |Tarau et a/., 1996a) is instrumental, 
as we use more than one independent grammar processor in the process. 

http_process_query (Socket , Qs , Css , FallBackServer) : - 
#<Qs, '/, sets input string from grammar 
match_word("GET "), 
match_bef ore(" " ,PathFile,_) , 
match_word("HTTP/") , 
#>_version, '/, 
! 

split_path_f ile (PathFile , Ds , Fs) , 
! 

has_text_f ile_suf ix(Fs,Suf ) , 
i 

■ ? 

( Suf =" .pro"->http_process_local (Socket ,Ds ,Fs , Suf ,Css) 

; write ( 'redirecting ' ) ,write_chars(Ds) ,write_chars (Fs) ,nl, 

http_send_line (Socket, "HTTP/1.0 302 Found"), 

make_cmd0( ["Location: ", FallBackServer, Ds,Fs] , Redirect), 

http_send_line (Socket .Redirect) , 

http_send_line (Socket , " " ) 

), 

close_socket (Socket) . 
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Our HTTP server component fits in 76 lines of code, and can be used to set up 
Prolog based Web processing by simply starting it in a command window on any 
Unix machine or PC. This involves no execution overhead, as is the case with CGI 
scripts. It basically offers the advantages of Apache server side includes (SSIs) or 
Microsoft's active server pages (ASPs), without requiring integration into a server, 
often subject to using the languages the server supports. 

2.6 Master Servers: Connecting a Web of Virtual Places 

A virtual place is implemented as a server listening on a port which can spawn 
clients in the same or separate threads interacting with other servers. 

A master server on a 'well-known' host/port is used as a registration service to 
exchange identification information among peers composed of clients and a server, 
usually running as threads of the same process. 

As in the case of the HTTP server we can derive a master server by specializing 
its interactor components through intuitionistic implications. 

3 Code migration and code acceleration techniques 

We have seen that setting up a self contained networking infrastructure (Web pro- 
tocols included) is a fairly simple task. The next step is emphasizing mobile agent 
support, which is particularly promising in synergy with knowledge processing ca- 
pabilities - a key strength of Logic Programming systems. 

3.1 Lazy code fetching 

In BinProlog, code is fetched lazily over the network, one predicate at a time, as 
needed by the execution flow. 

Code is cached in a local database and then dynamically recompiled on the fly if 
usage statistics indicate that it is not volatile and it is heavily used locally. 

The following operations 

host (Other_machine)=»rload(File) . 

host (Other_machine) =»code (File) =»TopGoal . 

allow fetching remote files rload/1 or on-demand fetching of a predicate at a time 
from a remote host during execution of TopGoal. 

This is basically the same mechanism as the one implemented for Java applet 
code fetching, except that we have also implemented a caching mechanism, at pred- 
icate level (predicates are cached as dynamic code on the server to efficiently serve 
multiple clients). 

3.2 Dynamic recompilation 

Dynamic recompilation is used on the client side to speed-up heavily used, rela- 
tively non-volatile predicates. With dynamically recompiled consulted code, listing 
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of sources and dynamic modification to any predicate is available, while the average 
performance stays close to statically compiled code (usually within a factor of 2-3) . 

Our implementation of dynamic rccompilation for BinProlog is largely motivated 
by the difficulty /complexity of relying on the programmer to specify execution 
methods for remote code. 

The intuition behind the dynamic recompilation algorithm of BinProlog is that 
update vs. call based statistics are associated to each predicate declared or de- 
tected as dynamic. Dynamic (re)compilation is triggered for relatively non- volatile 
predicates, which are promoted on the 'speed-hierarchy ' to a faster implementation 
method (interpreted -> bytecode -> native). The process is restarted from the 'eas- 
ier to change' interpreted representation, kept in memory in a compact form, upon 
an update. 

We can describe BinProlog's dynamic 'recompilation triggering statistics' through 
a simple 'thermostat' metaphor. Updates (assert/retract) to a predicate have the 
effect of increasing its associated 'temperature', while Calls will decrease it. Non- 
volatile ('cool') predicates are dynamically recompiled, while recompilation is avoided 
for volatile ('hot') predicates. A ratio based on cooling factors (number of calls, com- 
piled/interpreted execution speed-up etc.) and heating factors (recompilation time, 
number of updates etc.) smoothly adjusts for optimal overall performance, usually 
within a factor of 2 from static code. 

4 Computation Mobility with Threads and Continuations 

4-1 Why do computations need to be mobile? 

Advanced mobile object and mobile agents agent systems have been built on top of 
Java's dynamic class loading and its new reflection and remote method invocation 
classes. IBM Japan's Aglets or General Magic's Odyssey provide comprehensive 
mobility of code and data. Moreover, data is encapsulated as state of objects. This 
property allows us to protect its sensitive components more easily. Distributed 
Oz/Mozart provides fully transparent movement of objects over the network, giving 
the illusion that the same program runs on all the computers. 

So why do we need the apparently more powerful concept of mobile "live code" 
i.e. mobile execution state? 

Our answer to this question is that live mobile code is needed because is still 
semantically simpler than mobile object schemes. Basically, all that a programmer 
needs to know is that his or her program has moved to a new site and it is executing 
there. A unique (in our case move_thread) primitive, with an intuitive semantics, 
is all that needs to be learned. When judging about how appropriate a language 
feature is, we think that the way it looks to the end user is among the most impor- 
tant ones. For this reason, mobile threads are competitive with sophisticated object 
mobility constructs on "end-user ergonomy" grounds, while being fairly simple to 
implement, as we have shown, in languages in which continuations can be easily 
represented as data structures. 

And what if the host language does not offer first order continuations! A simple 
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way around this is to implement on top of it a script interpreter (e.g. a subset of 
Scheme or Prolog) which does support them! As it is a good idea to limit code 
migration to lightweight scripts anyway, this is a very practical solution for ei- 
ther C/C++ or Java based mobile code solutions, without requiring class-specific 
serialization mechanisms. 

4-2 Engines and Answer Threads 

Mobile computations really make sense only when multiple computation threads 
can coexist at a given place. We build this infrastructure in two steps: an engine 
encapsulating the state of an independent computation, and a thread actually run- 
ning it. Note that engines can also be used without multi-threading, as a form of 
coroutining. 

4-2.1 Engines 

BinProlog allows launching multiple Prolog engines having their own stack groups 
(heap, local stack and trail). An engine can be seen as an abstract data- type which 
produces a (possibly infinite) stream of solutions as needed. To create a new engine, 
we use: 

create_engine (+HeapSize , +StackSize , +TrailSize , -Handle) 

or, by using default parameters for the stacks: 
create_engine (-Handle) 

The Handle is a unique integer denoting the engine for further processing. To 'fuel' 
the engine with a goal and an expected answer variable we use: 

load_engine (+Handle , +Goal , +AnswerVar iable) 

No processing, except the initialization of the engine takes place, and no answer is 
returned with this operation. 

To get an answer from the engine we use: 

ask_engine (+Handle , -Answer) 

Each engine has its own heap garbage collection process and backtracks indepen- 
dently using its choice-point stack and trail during the computation of an answer. 
Once computed, an answer is copied from an engine to its "master" . 

When the stream of answers reaches its end, ask_engine/2 will simply fail. The 
resolution process in an engine can be discarded at any time by simply loading 
another goal with load_engine/3. This allows avoiding the cost of backtracking, 
for instance in the case when a single answer is needed, as well as garbage collection 
costs. 

If for some reason we are not interested in the engine any more, we can free the 
space allocated to the engine and completely discard it with: 

destroy_engine (+Handle) 
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The following example 2 in the BinProlog distribution ( |Tarau, 1998a| ) shows a se- 
quence of the previously described operations: 

?-create_engine(E) , 

load_engine(E, append (As, Bs, [1,2] ) ,As+Bs) , 
ask_engine(E,Rl) ,write(Rl) ,nl, 
ask_engine(E,R2) , write (R2) ,nl, 
destroy_engine (E) . 

Multiple 'orthogonal engines' as shown in Figure [21 enhance the expressiveness of 
Prolog by allowing an AND-branch of an engine to collect answers from multiple 
OR-branches of another engine. They give to the programmer the means to see as 
an abstract sequence and control, the answers produced by an engine, in a way 
similar to Java's Enumeration interface. 
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Fig. 2. Orthogonal Engines 



4.2.2 Threads 

Engines can be assigned to their own thread by using BinProlog's thread pack- 
age (currently fully implemented on Win32, Linux and Solaris platform). A unique 
primitive is needed, 

ask_thread(E,R) 

which launches a new thread R to perform the computation of an answer of engine 
E. On top of this facility each thread can implement a separate server or client, or 
become the base of a mobile agent. 

Thread synchronization is provided through monitor objects, handled with: 

2 See more in files library/engines. pi, progs/engtest.pl 
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synchronize_on (Monitor , Goal , Answer) 

The thread waits until the monitor is free, executes Goal, frees the monitor and 
returns Answer. 

The thread attached to an engine can be obtained with: 

get_engine_thread (Engine , Thread) 
and can be controlled directly with: 

thread_suspend (Thread) '/, suspends the thread 
thread_resume (Thread) resumes a suspended thread 
thread_join (Thread) '/, waits until a thread terminates 
thread_cancel (Thread) '/, discards a thread 

4-3 First order Continuations through Binarization 

Having hrst order continuations largely simplifies the implementation of mobile 
code operations: a thread is suspended, its continuation is packed, sent over the 
network and resumed at a different place. 

We will shortly explain here BinProlog's continuation passing preprocessing tech- 
nique, which results in the availability of continuations as data structures accessible 
to the programmer. 

The binarization transformation Binary clauses have only one atom in the body 
(except for some in-line 'builtin' operations like arithmetics), and therefore they 
need no 'return' after a call. A transformation introduced in ( |Tarau fc Boyer, 1990| ) 
allows us to faithfully represent logic programs with operationally equivalent binary 
programs. 

To keep things simple, we will describe our transformations in the case of definite 
programs. We will follow here the notations of ( |Tarau &: De Bosschere, 1993). 

Let us define the composition operator © that combines clauses by unfolding the 
leftmost body-goal of the first argument. 

Let A : -Ai , A 2 , . . . , A„ and B : -Bi , . . . ,B TO be two clauses (suppose n > 0, m > 
0). We define 

(A :-Ai,A 2 , . . . ,A„) © (B :-Bi, . . . ,B m ) = (A :-B 1; . . . ,B m ,A 2 , . . . ,A„)6» 

with 8 = mgu(Ai,Bo). If the atoms Ai and Bo do not unify, the result of the com- 
position is denoted as _L. Furthermore, as usual, we consider Ao:-true,A2, . . . ,A„ 
to be equivalent to A :-A 2 , . . . ,A„, and for any clause C, _LffiC = C©± = _L. 
We assume that at least one operand has been renamed to a variant with variables 
standardized apart. 

This Prolog-like inference rule is called LD-resolution. It has the advantage of 
giving a more accurate description of Prolog's operational semantics than SLD- 
resolution. Before introducing the binarization transformation, we describe two 
auxiliary transformations. 

The first transformation converts facts into rules by giving them the atom true 
as body. E.g., the fact p is transformed into the rule p :- true. 
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The second transformation, inspired by (W arren, 1981| ), eliminates the metavari- 
ables by wrapping them in a call/1 goal. E.g., the rule and(X,Y) :-X, Y is trans- 
formed into and (X,Y) :- call(X), call(Y). 

The transformation of ( |Tarau fc Boyer, 1990| ) {binarization) adds continuations 
as extra arguments of atoms in a way that preserves also first argument indexing. 

Let P be a definite program and Cont a new variable. Let T and E = p(Ti, T n ) 
be two expressions. 3 We denote by tp(E, T) the expression p(T\, T n , T). Starting 
with the clause 

(C) A : — Bi, £?2, B n . 
we construct the clause 

(C) ip(A,Cont) : -^(B u ip{B 2l i/,(B n , Cont))). 
The set P' of all clauses C ' obtained from the clauses of P is called the binarization 
of P. 

The following example shows the result of this transformation on the well-known 
'naive reverse' program: 

app([] .Ys.Ys.Cont) : -true (Cont) . 
app([A|Xs] ,Ys, [AlZs] ,Cont) :- 
app(Xs , Ys , Zs ,Cont) . 

nrev([] , [] ,Cont) : -true (Cont) . 
nrev([X|Xs] ,Zs,Cont) :- 

nr ev (Xs , Ys , app ( Ys , [X] , Zs , Cont ) ) . 

The transformation preserves a strong operational equivalence with the original 
program with respect to the LD resolution rule, which is reified in the syntactical 
structure of the resulting program, i.e. each resolution step of an LD derivation on 
a definite program P can be mapped to an SLD-resolution step of the binarized 
program P' . 

Clearly, continuations become explicit in the binary version of the program. We 
have devised a technique to access and manipulate them in an intuitive way, by 
modifying BinProlog's binarization preprocessor. Basically, the clauses constructed 
with : : - instead of : - are considered as being already in binary form, and not 
subject therefore to further binarization. By explicitly accessing their arguments, a 
programmer is able to access and modify the current continuation as a 'first order 
object'. Note however that code referring to the continuation is also part of it, so 
that some care should be taken in manipulating the circular term representing the 
continuation from 'inside'. 

4-4 Mobile threads: Take the Future and Run 

As continuations (describing future computations to be performed at a given point) 
are first order objects in BinProlog, it is easy to extract from them a conjunc- 
tion of goals representing future computations intended to be performed at an- 
other site, send it over the network and resume working on it at that site. The 

3 Atom or term. 
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natural unit of mobility is a thread moving to a server executing multiple local 
and remotely originated threads. Threads communicate with their local and re- 
mote counterparts, listening on ports through the Linda protocol, as described in 
\De Bosschere & Tarau, 1996\j . This combination of Linda based coordination and 
thread mobility is intended to make building complex, pattern based agent scripts 
fairly easy. 

4-4-1 Capturing continuations 

Before moving to another site, the current continuation needs to be captured in 
a data structure (see Appendix I). For flexibility, a wrapper capture_cont jf or/1 
is used first to restrict the scope of the continuation to a (deterministic) toplevel 
Goal. This avoids taking irrelevant parts of the continuation (like prompting the 
user for the next query) to the remote site inadvertently. 

A unique logical variable is used through a backtrackable linear assumption 
contjnarker (End) to mark the end of the scope of the continuation with encLcont (End) . 

^,From inside the continuation, call_with_cont/l is used to extract the relevant 
segment of the continuation. Towards this end, consume_cont (Closure , Marker) 
extracts a conjunction of goals from the current continuation until Marker is reached, 
and then it applies Closure to this conjunction (calls it with the conjunction passed 
to Closure as an argument). 

Extracting the continuation itself is easy, by using BinProlog's ability to accept 
user defined binarized clauses (introduced with ::- instead of :-), that can access the 
continuation as a 'first order' object: 

get_cont (Cont , Cont) : : -true(Cont) . 

4-4-% The Continuation Moving Protocol 

Our continuation moving protocol can be described easily in terms of synchronized 
source side 4 , and target side operations. 

Source side operations 

• wrap a Goal with a unique terminator marking the end of the continuation to 
be captured, and call it with the current continuation available to it through 
a linearly assumed fact 5 

• reserve a free port P for the future code server 

• schedule on the target server a sequence of actions which will lead to resuming 
the execution from right after the move_thread operation (see target side 
operations), return and become a code server allowing the mobile thread to 
fetch required predicates one a time 

4 which will be also shortly called the base of the mobile thread 

5 BinProlog's linear assumptions are backtrackable additions to the database, usable at most 
once. 
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Target side operations are scheduled as a sequence of goals extracted from the 
current continuation at the source side , and received over the network together 
with a small set of synchronization commands: 

• schedule as delayed task a sequence of goals received from the source side and 
return 

• wait until the source side is in server mode 

• set up the back links to the source side as assumptions 

• execute the delayed operations representing the moved continuation 

• fetch code from the source side as needed for execution of the goals of the 
moved continuations and their subcalls 

• shut down the code server on the source side 

Communication between the base and the target side proceeds through remote 
predicate calls protected with dynamically generated passwords shared between the 
two sides before the migratory component "takes off" . 

Initially the target side waits in server mode. Once the continuation is received on 
the target side, the source side switches to server mode (unless it already contains 
a running server thread), ready to execute code fetching and persistent database 
update requests from its mobile counterpart on the target side. 

Fig. El shows the connections between a mobile thread and its base. 

Note that when the base turns into a server, it offers its own code for remote use 
by the moved thread - a kind of virtual "on demand" process cloning operation, 
one step at a time. Since the server actually acts as a code cache, multiple moving 
threads can benefit from this operation. Note also that only predicates needed for 
the migratory segment of the continuation are fetched. This ensures that migratory 
code is kept lightweight for most mobile applications. Synchronized communication, 
using Linda operations, can occur between the mobile thread and its base server, 
and through the server, between multiple mobile threads which have migrated to 
various places. Note that servants described in section 12.31 can also be used to 
emulate servers in case of the ptocess is hosted in a component unable to listen on 
a server port. 

As our networking infrastructure, our mobile threads are platform independent. 
Like Java, BinProlog ( |Tarau, 1998b| > is a platform independent emulator based 
language. As a consequence, a thread can start on a Unix machine and move trans- 
parently to a Windows NT system and back. For faster, platform specific execution, 
BinProlog provides compilation to C of static code using an original partial trans- 
lation technique described in (|Tarau et al, 1996b). 



4-4-3 Emulating computation mobility through control mobility 

As shown in ( |Tarau et al., 1997b| ), part of the functionality of mobile computations 
can be emulated in terms of remote predicate calls combined with remote code 
fetching. An implicit virtual place (host+port) can be set as the target of the remote 
calls. Then, it is enough to send the top-level goal to the remote side and have it 
fetch the code as needed from a server at the site from where the code originates. 
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Fig. 3. Launching a mobile thread from its base 

Note however that this is less efficient in terms of network transactions and less 
reliable than sending the full continuation at once as with our mobile threads. 



4-5 Mobile Agents 

Mobile agents can be seen as a collection of synchronized mobile threads sharing 
common state ( |Tarau fc Dahl, 1996| ). Agents execute a set of goals, possibly spread 
over a set of different processes. In addition to usual Prolog computations, agents 
perform remote and local transactions in coordination with other agents, and react 
to event driven changes occurring on blackboards. 

Mobile agents are implemented by sending out mobility threads to a set of servers 6 
registered to a given master server. A pyramidal deployment strategy can be used 
to efficiently implement, for instance, push technology through mobile agents. Inter- 
agent communication can be achieved either by rendez-vous of two mobile threads 
at a given site, by communicating through a local Prolog database, or through 
the base server known to all the deployed agents. Communication with the base 
server is easily achieved through remote predicate calls with remote_run. Inter- 
agent communication can be achieved either by rendez-vous of two mobile threads 
at a given site, by communicating through a local blackboard, or through the base 
server known to all the deployed agents. Basic security of mobile agents is achieved 
with randomly generated passwords, required for remote jrun/1 operations, and 
by running them on a restricted BinProlog machine, without user-level file write 
and external process spawn operations. For more details on recent developments 
of mobile agent infrastructures and their applications, extending the framework 
presented in this paper, we refer to ( |Tarau, 1999c||Tarau, 19 99b Mik ler et a/., 1999"| 
|Tarau, 1999a||Rochefort et ai, 1999| ). 

In the latest version of BinProlog ( |Tarau, 1998a| ) two simple move/0 and re- 
turn/0 operations can be used to transport a mobile agent thread to a server 



possibly filtered down to a relevant subset using a 'channel'-like pattern 
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(listening on a default host/port) and back. The anaphoric there indicates that the 
mobile thread should be created on the server. Alternatively, here would indicate 
execution on a local thread. In this mobility scheme, the client simply waits until 
computation completes, when bindings for the first solution are propagated back. 

Window 1 : a mobile thread 

?-there , move .print In (on_server) .member (X, [1,2,3]) , 
return, println (back) . 

back 
X=l 

Window 2 : a server 

? -trust . 
on_server 

In case return is absent, computation proceeds to the end of the transported 
continuation. 

Note that mobile computation is more expressive and more efficient than remote 
predicate calls as such. Basically, it moves once, and executes on the server all future 
computations of the current AND branch until a return instruction is hit, when it 
takes the remaining continuation and comes back. This can be seen by comparing 
real time execution speed for: 

?-for(I, 1, 1000) ,remote_run(println(I)) ,fail. 

?-there, move, for(I, 1,1000) ,println(I) ,fail. 

While the first query uses remotejrun/1 each time to send a remote task to 
the server, the second moves once the full computation to the server where it ex- 
ecutes without further requiring network communications. Note that the move/0, 
return/ pair cut nondeterminism for the transported segment of the current con- 
tinuation. This avoids having to transport state of the choice-point stack as well 
as implementation complexity of multiple answer returns and tedious distributed 
backtracking synchronization. Surprisingly, this is not a strong limitation, as the 
programmer can simply use something like: 

?-there, move, findalKX, for(1, 1,1000) ,Xs) , return, member (X,Xs) . 

to emulate (finite!) nondeterministic remote execution, by collecting all solutions 
at the remote side and exploring them through (much more efficient) local back- 
tracking after returning. 

5 Related work 

Remote execution and code migration techniques are pioneered by | [ Amies et ai, 1985 
|Jul et al, 1988||Stamos fc Gifford, 1990| ). Support for remote procedure calls (RPC) 
are part of major operating systems like Sun's Solaris and Microsoft's Windows NT. 
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A very large number of research projects have recently started on mobile compu- 
tations/mobile agent programming. Among the pioneers, Kahn and Cerf's Know- 
bots dKahn fe Cerf, 1988| >. A mong the most promising recent developments, Luca 
Cardelli's Oblique project at Digital and mobile agent applications ( |Bharat fc Cardelli, 1995| 
and IBM Japan's aglets ( |IBM, 1999| ). Mobile code technologies are pioneered by 
General Magic's Telescript (see HGeneralMagicInc, 1997| for their last Java based 
mobile agent product). General Magic's Portico software combines mobile code 
technologies and voice recognition based command language (MagicTalk). 

Another mobility framework, sharing some of our objectives towards transparent 
high level distributed programming, is built on top of Distributed Oz ( |Van Roy et al., 1997| 
Hari di et al., 19971 ) a multi-paradigm language, also including a logic programming 
component. Although thread mobility is not implemented in Distributed Oz 2, some 
of this functionality can be emulated in terms of network transparent mobile ob- 
jects. The illusion of a unique application which transparently runs on multiple 
sites makes implementing shared multi-user applications particularly easy. We can 
emulate this by implementing mobile agents (e.g. avatars) as mobile threads with 
parts of the shared world visible to an agent represented as dynamic facts, lazily 
replicated through our lazy code fetching scheme when the agent moves. Both Dis- 
tributed Oz 2 and our BinProlog based infrastructure need a full language processor 
(Oz 2 or BinProlog) to be deployed at each node. However, assuming that a Java 
processor is already installed, our framework's Java client (see ( |Tarau et al., 1997b| 
|Tarau et al., 19 97a)) allows this functionality to be available through applets at- 
tached to a server side BinProlog thread. 

Implementation technologies for mobile code are studied in ( |Adl- Tabatab aT"e£ al., 1 996). 
Early work on the Linda coordination framework ( |Carriero fc Gelernter, 19'89||Gastellani fc Giancarini, 1 996 . 
|Brogi fc Giancarini, 1991] ) has shown its potential for coordination of multi-agent 
systems. The logical modeling and planning aspects of computational Multi- Agent 
systems have been pioneered by | |Cohen fc Perrault, 1979||Cohen et al., 1 989 Kowalsk i fc Kim, 1991| 
Wooldridge, 1992|[Coh"en fc Cheyer, 1994||Cohen fc Levesque, 1995||Lesperance et al, 1996| 
Chaib-draa fc Levesque, 1994| ). A survey of Logic Programming approaches to Web 
applications in terms of a classification into client-based systems, server-side sys- 
tems, and peer-to-peer systems is provided in ( |Loke, 1998| ). 

Let us point out a key difference between our framework and a typical Java 
based mobile code system. Conventional mobile code systems like IBM's Aglets 
(IBM, ~999| ) require serialization hints from the programmer and do not implement 
a fully generic reflective computation mobility infrastructure. Aglets do not provide 
code mobility as they assume that code is already available at the destination site. 
In practice this means that the mobile code/mobile computation layer is not really 
transparent to the programmer. 

In contrast, our architecture is based on building an autonomous layer consisting 
of a reflective interpreter which provides the equivalent of implicit serialization and 
supports orthogonal transport mechanisms for data, code and computation state. 
The key idea is simply that by introducing interpreters spawned as threads by a 
server at each networked site, computation mobility at object-level is mapped to 
data mobility at meta-level in a very straightforward way. A nice consequence is 
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transport independence coming from the unifrom representation of data, code and 
computation state allowing Corba, RMI, HLA, as well as plain or multicast sockets 
to be used interchangeably as our transport mechanism. 

6 Conclusion 

We have described how mobile threads are implemented by capturing first order con- 
tinuations in a data structure sent over the network. Supported by lazy code fetching 
and dynamic recompilation, they have been shown to be an effective framework for 
implementing mobile agents. 

The techniques presented here are not (Bin) Prolog specific. The most obvious 
porting target of our design is to functional languages featuring first order con- 
tinuations and threads. Another porting target is Java and similar object oriented 
languages having threads, reflection classes and remote method invocation. We are 
working on a Java based component using an embedded continuation passing Pro- 
log interpreter which is already able to interoperate with BinProlog (latest version 
at http : //www . binnetcorp . com/ Jinni| ) . An interesting application is using Bin- 
Prolog as an accelerator for Java based threads through migration to BinProlog, 
execution of a computationally intensive task and return to the Java component. 
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Appendix I: Capturing First Order Continuations in BinProlog 

°/ t calls Goal with current continuation available to its inner calls 
capture_cont_f or (Goal) :- 

assumeal(cont_marker(End)) , 
Goal, 

end_cont (End) . 

7. passes Closure to be called on accumulated continuation 
call_with_cont (Closure) :- 

assumed(cont_marker (End) ) , 

consume_cont (Closure, End) . 

7. gathers in conjunction goals from the current continuation 
7. until Marker is reached when it calls Closure on it 
consume_cont (Closure .Marker) :- 
get_cont(Cont) , 

consume_contl (Marker, (_,_,_, Cs) , Cont .NewCont) , 7. first _ 
call (Closure, Cs) , 7. second 

7. sets current continuation to leftover NewCont 
call_cont (NewCont) . '/, third 

7. gathers goals in Gs until Marker is hit in continuation Cont 
7. when leftover LastCont continuation (stripped of Gs) is returned 
consume_cont 1 (Marker , Gs , Cont , LastCont ) : - 
strip_cont (Cont , Goal , NextCont ) , 

( NextCont==true-> ! , errmes (in_consume_cont , expected_marker (Marker) ) 
; arg ( 1 , NextCont , X) , Marker==X-> 

Gs=Goal , arg ( 2 , NextCont , LastCont ) 
; Gs=(Goal,OtherGs) , 

consume_contl (Marker ,0therGs .NextCont .LastCont) 

). 

7. this 'binarized clause' gets the current continuation 
get_cont (Cont, Cont) : :-true(Cont) . 

7. sets calls NewCont as continuation to be called next 
call_cont (NewCont, _) ::- true (NewCont) . 
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Appendix II: Thread Mobility in BinProlog 

'/, wraps continuation of current thread to be taken 
by inner move_thread goal to be executed remotely 

wrap_thread(Goal) :- 

capture_cont_f or (Goal) . 

% picks up wrapped continuation, 

'/, jumps to default remote site and runs it there 

move_thread: - 

call_with_cont (move_with_cont) . 

moves to remote site goals Gs in current continuation 
move_with_cont (Gs) :- 

7. gets info about this host 
detect_host (BackHost) , 
get_f ree_port (BackPort) , 
def ault_password(BackPasswd) , 
def ault_code(BackCode) , 

'/, runs delayed remote command (assumes is with +/1) 
remote_run( 
+todo( 

host (BackHost ) =»port (BackPort ) =»code (BackCode) =» ( 
sleep (5) , '/, waits until server on BackPort is up 
'/, runs foals Gs picked up from current continuation 
(Gs->true;true) , °/, ignores failure 
"/, stops server back on site of origin 
stop_server (BackPasswd) 

) 

) 

), 

'/, becomes data and code server for mobile code until is 
'/, stopped by mobile code possessing password 
server_port (BackPort) =»run_unrestricted_server . 



